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USING AN EFFECTIVE TESTBENCH IS AN IMPORTANT PART 
OF PROGRAMMABLE-LOGIC SIMULATION. KNOWING 
WHICH VHDL FEATURES SUPPORT HIGH-LEVEL MODELING 
HELPS REDUCE YOUR TESTBENCH-DEVELOPMENT TIME 

Behavioral modeling 
in VHDL simulation 



The effective use of simulation offers sever- 
al advantages for product-development teams. 
The major benefits of effective simulation are 
quicker time to market, increased quality, and de- 
creased risk. By offering enhanced controllability 
and observability, a well-designed simulation can 
test situations that are difficult to generate in a pro- 
totype debugging environment. You can easily check 
boundary conditions when you have complete con- 
trol of the environment. Worst-case conditions may 
include the simultaneous occurrence of independ- 
ent functions that are difficult to achieve in an ac- 
tual system. You can set up these conditions in a con- 
trollable simulation. ~ 
Simulation also enables more extensive * 



has had to build a second prototype board because 
the design needed so many changes. Designing a 
new pc board easily adds weeks to a schedule. With 
higher level techniques, you can use simulation to 



COMMON SIMULATION MISTAKES 



A key question is, "What keeps simulations from 
being efficient?" The basic problem is often using 
low-level methods, such as waveform-vector entry, 
for large and complex designs. This technique, in 



re 1 



observations of your design. Internal signals are 
available, regardless of whether spare I/O pins are 
on the device. You can even more easily probe ex- 
ternal signals during simulation. With a few key- 
strokes or mouse-clicks, you can use a good logic 
simulator to probe a 64-bit data bus in seconds; try 
that with a logic analyzer. It could take the better 
part of a day in the lab to get a complex design set 
up for monitoring. 

These same advantages of controllability and ob- 
servability allow you to more quickly and easily 
catch errors with simulation than with hardware de- 
bugging. Furthermore, you can change the design 
more quickly in a simulation than on a hardware 
prototype. This feature shortens the debugging cy- 
cle and eases integration, especially if you simulate 
different modules together before integration. Sim- 
ulation not only decreases the debugging cycle, but 
also requires fewer prototype hardware-design 
changes. This feature is good news to anyone who 
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turn, causes many of the classic failures 
in system simulation, including insuffi- 
cient fault coverage and inadequate — 

circuit-response characterization. 

In a large design, it is difficult to get prop- 
er fault coverage with low-level methods, 
which force you to manually generate 
each vector and test case. When vector 
generation is tedious and time-consum- 
ing, it may be difficult to specify all the 
test scenarios of interest. Even if you 
specify the test cases, it may be difficult 
to make them complete. Because most 
projects using simple techniques use vi- 
sual inspection to qualify circuit re- 
sponses, you may miss many visible-cir- 
cuit malfunctions. More powerful sim- 
ulation techniques actually simplify the 
task of design verification. Some people 
believe that the only methods of han- 
dling complexity are hierarchy and ab- 
straction. Modeling makes use of both 
hierarchy and abstraction to allow the 
simulation of a complex system to be 
both manageable and efficient. 

GOALS FOR A GOOD TESTBENCH 

The key requirements of a good test- 
bench are completeness, ease of use, flex- 
ibility, reusability, and runtime efficien- 
cy. These features are interrelated: A 
flexible design is easier to use, easier to 
complete, and to easier to reuse. 

High fault coverage is essential for an 
effective simulation project. A good sim- 
ulation strategy facilitates the develop- 
ment of a testbench that covers all perti- 
nent operational scenarios. You can best 
accomplish this goal by using techniques 
that allow simulation designers to work 
at a fairly high level of abstraction. It is 
easier to follow the flow of a simulation 
if you can specify the test scenarios at a 
macro level rather than at the atomic lev- 
el. A good simulation technique should 
support a high level of abstraction. With 
many features that support behavioral 
modeling at a high level, VHDL easily 
satisfies this requirement. Simulation 
methods based on modeling of system- 
level components naturally work at a 
high level of abstraction. For example, 
having a model of a CPU allows you to 
specify the types of bus cycles. Building 
the testbench around the CPU model al- 
lows you to set up the test patterns in a 
manner similar to that of a programmer 
writing a diagnostic program. At a high 
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By using functional models in your testbench for the unit under test and the surrounding board- 
level components, you create a more efficient testbench, either with a fixed CPU model (a) 



a CPU model that you can modify with a 



level, the simulation flows naturally by 
setting up DMA transfers, programmed 
I/O, and various bus operations. This ap- 
proach allows an engineer to focus on the 
functional requirements of the test, leav- 
ing bit manipulation to the hardware 
model. 

Although a simulation method should 
be easy to use, this strategy involves a 
trap: The methods that are easy to use for 
small designs do not scale well to more 
complex designs. Using a library of pre- 
verified functional models, you can eas- 
ily build a testbench that has compre- 
hensive timing and data checking. A 
good library has these features in the 
models themselves. It is also easy to write 
test cases because the "virtual system" of 
the testbench mimics the operation of 
the actual hardware. Anyone who under- 
stands the operation of the hardware sys- 
tem can understand the steps needed to 
exercise the design being tested. 

A good simulation methodology must 
be flexible enough to allow changes to 
the simulation as the test system gains 
knowledge or test requirements change. 



file (b). 



If a testbench is equivalent to a pile of 
"spaghetti code," modifying the test- 
bench is difficult. Object-oriented soft- 
ware techniques are available to offer this 
kind of flexibility to computer pro- 
grammers. Embedding functions into 
functional-model components offers 
similar benefits to engineers designing 
complex chip or system simulation. To 
be easily modified, hardware designs 
should have strong cohesion and loose 
coupling. The control path in a design 
should be simple. By mimicking the 
structure of the system design in a test- 
bench, you can easily duplicate the be- 
havior of the system. If the system design 
changes, you can straightforwardly 
modify the testbench model to ensure 
that it matches the system. Modeling also 
helps flexibility in other ways. Defining 
functions associated with component 
models allows you to make changes in 
one place that can have effects every- 
where you use the component. Contrast 
this with the global search-and-replace 
or cut-and-paste operations so common 
with simple testbenches. Proper model- 
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This top-level schematic of a CPLD-based SRAM-controller design shows how you link the controller to models for all the other major components in 
the design. 



ing should yield flexible simulation ar- 
chitectures. 

Design reuse is becoming a major fac- 
tor in closing the productivity gap in 
deep-submicron VLSI design method- 
ologies. High-density FPGAs and CPLDs 
that promise fast time to market require 
similar techniques. Because chips are in- 
herendy reusable, so are the simulation 
models that mimic their behavior. Just as 
designers habitually use many of the 
same components in many designs, you 
can also reuse good simulation models. 

A good testbench must execute quick- 
ly. Modeling has no inherent advantage 
over low-level methods. Just as a good as- 
sembly-language program is generally 
faster than one written in a high-level 
language, a low-level testbench is proba- 



bly faster than a corresponding modeling 
simulation. For complex simulations, the 
advantages of modeling far outweigh a 
decrease in simulation speed. The execu- 
tion time for a typical FPGA is smaller 
than the time spent developing the sim- 
ulation suite. Besides, when you proper- 
ly partition a simulation according to 
functional entities, or models, it may be 
easier to isolate the time-consuming por- 
tions of a simulation and optimize these 
portions. In general, a well-designed 
modeled testbench does not have to be 
significandy slower than a low-level test- 
bench. Furthermore, although individual 
simulation cycles in low-level modeling 
may execute faster, the overall objective 
of providing a thoroughly simulated de- 
sign is faster using higher level tech- 



niques, because fault coverage is more ef- 
fective and less prone to error. In other 
words, using lower level techniques takes 
much longer to get the fault coverage that 
higher level techniques provide. 

Figure la shows a block diagram of a 
typical simple testbench. In the code ex- 
ample of Listing 1, the code structure is 
simple and flat. The unit under test is in- 
stantiated as a component, and one 
process controls the main test sequence. 
Inline code generates circuit stimuli, and 
multiple wait statements control the 
main sequence timing. Alternatively, you 
could use multiple after conditions in a 
transport statement to control timing. 
Most novice users of VHDL simulation 
validate circuit responses by inspecting 
the resulting waveforms. Such a test- 
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TABLE 1 



Feature 



Application 
to aid simulation 



Attributes 



Gate-level versus RTl or 
behavioral models 

Alternative implementations 
for stepwise refinement 



VHDL attributes extract 



Benefits 

Some difficult-to-simulate structures, such as wide < 
problems for a simulation; use multiple architectures to i 
counter that will reach terminal count much sooner than the < 
needs for the application. 

You can use multiple architectures to allow a testbendi to instantiate the 
presynthesis RTL model or the postfit gate-level model, depending upon the 
VHDL configuration associated with the project 

The first or simplest simulation model may not be the most efficient You can 
switch alternative models into and out of the simulation to compare results. 
For example, you could replace the original CPU model with a newer model 
that interfaces to a text-file language parser. 




Hal 



m H 

■ 



case 



for loop 



while loop 



infinite loop 



exit 



These statements are useful for synthesis and simulation for describing com- 
plex, arbitrary conditions for controlling logic Although these st ate ment s can 
be tricky for synthesis because complex statements can generate large amounts 
of logic simulation does not suffer because testbenches do not synthesize into 
hardware. 

As in synthesis, case statements are useful for structured control, functioning as 
multiplexers when you synthesize them or use them in testbenches. 
For loops allow for a number of iterations, and you can use the index 

! to sequence through indexed arrays or other data structures. They 
I for applying pattern vectors from a text file or internal array to a 
design under test 

While loops specify the conditions under which the loop will continue to 
execute. They are useful for simulations, but synthesis does not widely 



An infinite loop is one that has no specified terminating condition and usually 
Includes an exit condition. An infinite loop can cause the simulator to "hang" 
If a run command is used without a limit 

The exit statement causes any loop to terminate if the exit condition specified 



is satisfied. 



statements wdflRjr 

wait until (comfit? 
wait on (seasiilw 



Assert s t ate ments 
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Response checking and 
message generation 
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Generics Design reuse 

models 



Assert s t ate me nt s generate messages based on whether a specified 
condition is true; they are useful with serf-checking models using 
the signal attributes to check behavior. 



. > 





information, into an entity. This feature allows for parameterized models, 
which are more flexible m their application or reuse. For i 
develop a variable-size and -width SRAM model. Generics also allow you to 
pass delays into each instance of a component's instantiation. 
■ 



Miwiafltiiirii^m' ii win n ' * ^- 



Packages allow you to define the key parameters of a test program in a com- 
s is useful for any type of complex design, especially for 
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bench typically does little 
or no qualification of cir- 
cuit performance. 

The lack of functional 
partitioning in this test- 
bench makes it difficult to 
implement complex con- 
trols. For example, you may 
want to vary control-signal 
timing to verify that the 
unit under test can tolerate 
all the allowed variations 
on its inputs. An examina- 
tion of the testbench code 
shows that a single wait 
statement, wait for clk_ 
period, affects the timing of 
all subsequent signal as- 
signments. It can be difficult to manage 
the timing of the various stimulus signals 
when their timing is interactive. This sit- 
uation becomes worse when someone 
copies and pastes these wait statements 
multiple times into a large process. The 
more complex the design, the less ade- 
quate these methods become. Static-tim- 
ing schemes often cannot handle inter- 
active chip interfaces. The need to 
implement such handshaking is often 
what first drives engineers to consider 
modeling. A process can use conditional 
sequential statements, if -then-else or case 



LISTING 1 -USEFUL FILE-I/O COMMANDS 



main stimulus process 
p_stim: process 
begin 

main stimulus process 
p_stim: process begin 
csn <- 'i'j 
wen <- '1'; 

end_in <- (others -> '0'); 
rst~~<- '1'; 

wait for clk_period*2 ; 
rat <- '0'; 
wait for clk_period; 

assert (out_bus ■ x"5") report "Out did not 
severity error; 
waitn <■ '0'; 
wait for clk_period*2; 
waitn <- '1*; 
wait for dk_period*20; 
assert false 

report "Reached end of stimulus." 
severity note; 
end process; 



statements, that actively interact with the 
unit under test. Although you can per- 
form this handshaking without building 
a model, you would not unify structure 
and function. The discipline of model 
building is helpful because it immediate- 
ly suggests that a testbench's function 
should mimic the interactive nature of 
the system under test. 

WAIT VERSUS TRANSPORT STATEMENTS 

One of the most challenging aspects of 
using HDL simulators is the concept of 
time. In VHDL, programmers broadly 



classify code as concur- 
rent or sequential. Mul- 
tiple sequential blocks 
of code execute concur- 
rently and use sensitivi- 
ty lists or wait state- 
ments to pace their 
execution. Within a 
process, the software 
schedules events, but 
simulation goes no 
faster until the program 
encounters a wait state- 
ment. You can use mul- 
tiple wait statements to 
control the sequencing 
of various signals, but 
this approach causes the 
timing of individual signals to interact, 
complicating their control. Similarly, you 
can use transport-delay specifications to 
time signal transitions, but these spe- 
cifications control the timing of a series 
of transitions on a single signal, inde- 
pendently of all other signals. You still 
need a wait statement to speed simula- 
tion, but the timing sequence in the 
transport statement rolls off the simula- 
tion-event wheel as time advances due to 
one or more wait statements. These wait 
statements may be in any part of the 
code. It is easier to individually specify 



TABLE 2- 



Slgnarevent 



signal 'last_event 



Description and usage 

Returns a true value if the signal had an event (changed value) during the current simulator tick; useful for 
synchronizing events with a strobe signal. For example, when the WR~ goes high on an SRAM, then a write 
cycle may have taken place. This time b appropriate for executing the appropriate code in a process that 
models an SRAM. 



Returns the time elapsed since the most recent event on a signal; useful in an SRAM model to see whether 
the address had been stable throughout the duration of the write cycle. 
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typt'\magt{expresshii) 



typt\a\ue(string) 
signal 'stable(ftije) 

*qutte(fltoe) 

■■■■ I 
signal transaction 



! a true value if any transaction (scheduled event) occurred on a signal during the current i 

tick. . ■ • . 

Creates a text image of the spedfteal afi^mSBMfSwt reporWMexpre^ must be 5 

ry^asnutto.*tu^the.^tttrik 
Returns a value of the attached type. 



Creates a Boolean signal that becomes true when the signal b stable for the specified time period; could be 
used for checking setup-and-hold times. 



Creates a bit signal that toggles when a transaction or event occurs on a signal. 




(ypeValfinteger) 



the value of an 

of 0, and all 



type from the specified Integer value; the first < 
of 1, 2, 3, and so on. 



:a 
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signal transitions with transport state- 
ments, but it is generally more difficult to 
unravel the timing when stepping 
through code during debugging. 

You can use both methods of control- 
ling signal sequencing and timing in a 
given testbench. Wait statements are eas- 
iest to use when a group of signals repet- 
itively and simultaneously change. This 
situation is typical of synchronous sig- 
nals simultaneously changing during 
every clock cycle. When modeling an 
asynchronous interface, such as with an 
Intel-style microprocessor, you may need 
to individually adjust signals. Using wait 
statements, which delay the application 
of all signals downstream, this approach 
involves a complex problem. Individual 
transport statements allow you to speci- 
fy a series of transition delays for each 
signal, defining a waveform for each sig- 
nal. Although this technique decouples 
signal timing, it also makes it more diffi- 
cult to visualize the sequencing of indi- 
vidual timing. For instance, if a key re- 
quirement is to guarantee an address- 
hold time from the end of a write strobe, 
it may be easier to use a wait statement to 



move the simulation-timing wheel for- 
ward a fixed time between the unasser- 
tions of the write strobe and address bus. 
You may want to experiment to figure 
out what fits your preferences and design 
requirements. Multiple wait statements 
are easier to step through during debug- 
ging than are transport statements, but 
transport statements are more compact 
for describing the same behavior. With 
the modularity of modeling, it is easy to 
use each mechanism where it best fits. 

You can improve this simple model 
slightly by adding statements that check 
the responses of the unit under test (Fig- 
ure lb). Automatically checking data is 
a mixed blessing in such a simple scheme. 
It is difficult, with the simple testbench, 
to have enough control to do all the 
checking you need to validate the circuit 
responses. Just sampling the data at the 
correct time can be difficult. Checking 
setup-and-hold times and all the other 
parameters of importance is a daunting 
task when the program forces all the code 
for the simulation to reside in one 
process in a flat model. You can some- 
what remedy the situation by setting up 



multiple processes to check signals, pa- 
rameters, or interfaces, but again this ad 
hoc process is difficult to control, man- 
age, and maintain. Because you mix 
structure and function, it is also difficult 
to reuse such designs in new applications. 

KEY MODELING CHARACTERISTICS 

The basic idea behind a testbench 
based on modeling is to create function- 
al models of all board-level components 
that surround the unit under test (Figure 
2). The top-level file usually contains 
structural VHDL code that ties the vari- 
ous models together as instantiated com- 
ponents. At least one of the components 
is the unit under test. The other compo- 
nents are functional equivalents of the 
other devices on the board. In this ex- 
ample, you need to simulate a Lattice 
CPLD. The design is an interface between 
a 33-MHz i960RP microprocessor and 
dual banks of SRAM. It allows the system 
to access the memory at half the bus 
speed by alternating access to two banks 
of SRAM. The CPLD is the unit under 
test, but you have to model the CPU, 
clocks, transceivers, and SRAM. The 



TABLE 3- 




T\\e_open(file,name,mode) 
¥i\e_Of>en(status r file,name,mode) 


Opens file object with the specified name for a mode of read, write, or append. 


FiledosefSfe) 


Closes specified file. 


Read(ffleoK«fl Reads from specified file Into specified oble 


Read\me(fileAne) 


Read a line from the specified file. 


Writeline(ff/eJ/nej 


Writes a line to the specified file. 






TABLE 4- 


Additional text-handling commands adt 
Apply exponent 


led by the standard textio package 

This procedure reads in numeric characters and the "_" character and uses them as an exponent for 
the real parameter. It indicates the success of the operation through the ok parameter. 


HHflHSSSBHHHHil 


fplTMs procedure reads la numeric characters and the character and uses them as an exponent for 


ftppiy_iracuon 






into a fractional number. It indicates the status of the conversion throught the ok parameter. 






Extract integer 


Once the optional leading sign is removed, an integer can contain only the digits "0" through "9" and 
the "_" (underscore) character. VHDL disallows two successive underscores and leading or trailing 

underscores. 






Crowjine 


This procedure increases the length of the specified line by the indicated increment 
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SRAM models can check all the signals 
from the unit under test on every access 
cycle. You can easily put all the required 
setup, hold, and pulse-width checks into 
the SRAM model. It would be difficult to 
put those checks into a simple structure, 
especially when you need to include all 
the other checks into the test, as well. A 
designer's task is easier with signal check- 
ing embedded in the functional models. 

One interesting aspect of modeling a 
functional system involves defining the 
overall control mechanism. In a simple 
testbench, a test designer most naturally 
places the main test process at the top lev- 
el of the hierarchy, often in a testbench 
comprising one file. In a testbench based 
on models, the controller of data flow in 
a design parallels the controller in the ac- 
tual system. For intelligent cards, this 
controller is the CPU or microcontroller. 
You would probably control slave adapter 
cards via the system bus. In this example, 
the i960 processor is the system con- 
troller, and the simulation naturally flows 
through the CPU model. The main con- 
trol process is not even at the top level of 
the testbench; it is embedded in the CPU 
model. This situation may seem strange 
to those who have used only simple test- 
benches, but it is a natural consequence 
of modeling. 

In this example, both the memory and 
the SRAM controller are slave devices. 
Because the CPU model drives the sim- 
ulation, a designer needs only to specify 
the sequence of bus cycles with a method 
to route data into and out of the design. 
The CPU model generates all individual 
bus signals. By handling the simulation 
at this higher level, a designer can deal 
with system-level functions and let the 
models handle the details. Once you 
generate the models, you can develop a 
complex functional simulation more 



quickly than with low-level methods. 

Modeling often separates validation of 
control-path functions from validation 
of datapath functions. Simple methods 
merge these functions, again complicat- 
ing the issues of simulation control. The 
model generally verifies control-path 
functions. With an SRAM model, you 
can easily determine what code needs to 
go into a model to verify that the control 
signals are functioning properly. Putting 
timing checks into an SRAM model al- 
lows you to place the checks in one loca- 
tion that is active whenever the model ac- 
cesses the SRAM. You can implement 
other control-path-timing and function- 
al verification in behavioral models. You 
can sometimes internally test datapath 
functions in the models, as in the case of 
a CRC generator/checker. Generally, it is 
more reasonable to check the datapath at 
a higher level of abstraction. In this case, 
it is more convenient to have the CPU 
model perform write- and read-back cy- 
cles to verify the operation of the mem- 
ory subsystem. The CPU model verifies 
data integrity. You do the verification in 
much the same manner as writing self- 
test code for a microprocessor. For a ful- 
ly functional CPU model, you could use 
the same code you developed for system 
self-test with limited modification to run 
the simulation; the converse also is true. 

Fortunately, you need not use arcane 
methods to start designing modeling 
testbenches. Unlike object-oriented pro- 
gramming, testbench modeling does not 
require a wholesale paradigm shift in the 
way engineers think of system design. Be- 
cause the structure that the testbench 
mimics is the hardware design, building 
a testbench with functional models re- 
quires the same analytical methods that 
engineers have developed through years 
of working with schematics and lab 



equipment. You simply replace the com- 
ponents on a board with functional com- 
ponents in a VHDL design and then fig- 
ure out how to model each component. 
Planning a simulation is much like plan- 
ning the early stages of prototype de- 
bugging when a hardware engineer typ- 
ically writes diagnostic code. 

Modeling is most advantageous when 
you adopt it on a companywide basis. 
You must design, implement, and vali- 
date any models that you don't buy. You 
have to validate models at a low level of 
abstraction, looking explicidy at detailed 
function and timing. An engineer using 
the models to test a design can be the 
same engineer who validates the models. 
Because modeling involves the encapsu- 
lation of function, this scenario helps 
prevent self-fulfilling prophecies, in 
which the testbench designer perpetuates 
the same faulty assumptions a system's 
designer makes. You can organize model 
building, plan it into the design schedule, 
and divide it among the design-team en- 
gineers. You should establish standards to 
ensure the consistency and quality of the 
generated mo,dels. This approach ensures 
the existence of a library of prevalidated 
models that are a valuable resource for 
enhancing the simulation capabilities 
and efficiencies of a design team. 

If the effort of developing complex 
models is beyond the capability of an en- 
gineering group, it should consider ob- 
taining models from outside sources. 
Standards compliance often dictates the 
need for a fully validated and compliant 
model. All standard-bus models, includ- 
ing PCI, SCSI, VME, and ISA, are avail- 
able, as are models that intellectual- 
property (IP) vendors often supply. The 
Logic Modeling Division of Synopsys of- 
fers a variety of bus-interface models that 
aid in verifying compliance and interop- 
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erability of standard-bus designs. Many 
other third-party vendors also supply a 
variety of cores. You can find an impres- 
sive list of noncommercial model sources 
on the Web (references 1, 2, and 3). 

MODELING AND ABSTRACTION 

VHDL's inventors envisioned the lan- 
guage as a pure modeling language. Ear- 
ly adopters of VHDL for logic synthesis 
had problems in that many useful mod- 
eling constructs were inappropriate for 
synthesis. Second, VHDL dictates that 
you implement many of the necessary 
features that are part of Verilog, such as 
type conversions, as library functions. In 
contrast, you can use the full range of 
VHDL's modeling capability for generat- 
ing behavioral-simulation models. You 
can specify complex behavior without 
adhering to the RTL conventions that 
synthesis supports. You can even model 
analog and mechanical systems using 
VHDL's mathematical functions. (The 
analog extensions now under consider- 
ation for VHDL are primarily extensions 
of the language's currently available math 
functions.) Because you need not syn- 
thesize the simulation models, you can 
use many high-level behavioral con- 
structs to simplify functional-model gen- 
eration. Defining functions according to 
the components that perform them 
yields a functional decomposition that 
encourages a higher level of abstraction. 
This technique decouples the functional 
specification from the low-level opera- 
tional details and simplifies writing the 
test program. Tables 1 and 2 summarize 
many of the features and attributes of 
VHDL that are useful for generating 
modeling simulations. 

Although not a feature of VHDL per 
se, most VHDL- and Verilog-simulation 
packages allow users to interface exe- 
cutable programs to the simulation. 
These programs, usually written in C or 
C + + , allow users to implement com- 
plex behaviors without the speed or 
space overhead of using VHDL models. 
For example, modeling a large SRAM 
model in C allows the operating-system 
resources to implement data storage. You 
could model a memory that exceeded the 
size of available RAM on the PC or work- 
station if the operating system could 
cache data and swap it to disk when nec- 
essary. Alternatively, you could model the 
system in C and use the simulator to al- 
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low the C program access to the compo- 
nent models in the simulator. This ap- 
proach could be faster than VHDL for 
large simulations but would require an 
environment including both VHDL and 
C development tools. This approach 
might be helpful for an engineer work- 
ing with systems simulated in C before 
partitioning and handing them off to a 
circuit designer for implementation. 

WHAT IS A CONFIGURATION? 

VHDL defines a configuration design 
unit that is roughly analogous to a part 
list for a pc-board assembly. You require 
a configuration because a given entity 
can involve multiple architectures. A 
configuration declaration, which the 
VHDL keyword configuration specifies, 
identifies the pairing or binding of an ar- 
chitecture to each entity. You do not ex- 
plicitly need configurations unless you 
specify multiple architectures. Configu- 
rations are most useful for simulation; 
synthesis tools do not generally support 
them. 

USING VHDL, A SYSTEM 
DESIGNER CAN MODEL 
A CIRCUIT AT MULTIPLE 
LEVELS OF ABSTRACTION. 

The 1987 VHDL standard's file-I/O 
functions were somewhat limited. The 
1993 version added syntax enhance- 
ments and new features to extend the 
language's file-I/O capabilities. You can 
use the VHDL file-I/O functions in var- 
ious ways. Primary uses are retrieving 
and applying stimulus vectors; storing 
response vectors and expected respons- 
es for comparison; formatting reports; 
and reading custom test-language files, 
which the program then parses. 

You can use the test-language- file 
reading with a higher level of abstraction 
to control the simulation. Because you 
specify the commands at a functional 
level, functional models, which respond 
to each command according to their pro- 
gramming, perform the detailed imple- 
mentation. This powerful technique 
drives simulations at a high level. You 
leverage your system-level knowledge to 
the greatest degree because you exercise 
control at a level that is most convenient 
for checking system functions. When a 



text file determines control flow, the cus- 
tom test language becomes specific to a 
simulation. The VHDL simulation inter- 
prets the code. You can quickly generate 
and check new test cases because you 
need not compile the new code, because 
it is not a part of the VHDL testbench. 
Table 3 shows the most common basic 
file-I/O commands. Table 4 shows the 
added common commands from the 
standard text-I/O package. 

DESIGNING A TESTBENCH USING MODELS 

The IEEE offers resources, including 
online notes, that are excellent guidelines 
for writing behavioral models (refer- 
ences 4, 5, and 6). The key points are to 
model a system at multiple levels of ab- 
straction, to hide the system's structure, 
to focus on behavior and functionality, 
to ignore timing at the top level of ab- 
straction, to follow standard practices of 
software engineering, to simplify main- 
tenance and reuse, to structure the de- 
sign, to define each component to have 
strong cohesion, to define a loosely cou- 
pled set of components, to use top-down 
iterative refinement, and to use abstract 
data-typing to hide and encapsulate data. 

Using VHDL, a system designer can 
model a circuit at multiple levels of ab- 
straction. When modeling in VHDL, it 
is important to follow standard practices 
of software engineering. Otherwise, the 
model becomes difficult to maintain, 
even for the person who wrote it. In ad- 
dition, to aid the reuse of models, you 
should carefully and with reuse in mind 
even create throwaway models. Typical 
model design and coding practices in- 
clude structuring the design; iteratively 
refining a high-level view of the model 
down to its final form; employing ab- 
stract data typing to hide and encapsu- 
late data; and organizing the individual 
model components so that they are 
loosely coupled with few interface signals 
and have strong cohesion, keeping 
strongly related functions in the same ar- 
chitectural body. 

In Figure 3, the schematic links the de- 
sign of a CPLD-based SRAM controller 
to models for all the other major com- 
ponents in the design. This Ramix Corp 
CPLD design targets a Lattice M4A5- 
192/96-7VC part. Ramix chose this part 
because the speed locking of the inter- 
nal delays allowed the part to work at an 
effective internal frequency of 1 32 MHz. 

www.ednmag.com 



iUU>\ f U I UfVC 




When you can't afford the price of 
failure, you can't afford to settle for 
second best. That's why leading 
aircraft OEMs around the world rely 
on Janco switches, potentiometers, 
and switching assemblies for a 
wide range of flight critical 
applications. If you'd like to see 
how we could put this technology 
to use for you. . .contact our 
engineering department today. 
We'll fax initial drawings with 
specifications in just hours. 

AN ESOP C0RP0FW1ON 

31 1 1 Winona Ave., Burbank, CA 91 504 
T. 818.846.1800. F. 81 8.842.3396 
Visit us on the web: 
http://www.jancocorp.com 
e-mail: jancoengr@aol.com 



designfeature wnr simulation 



Circle 3 or visit www.ednmag.com/infoaccess.asp 

64 edn I October 28, 1999 



The design required state changes on 
both edges of a 66-MHz clock. Using the 
highest speed would push the usable fre- 
quency to around 180 MHz. 

The CPU model generates the bus cy- 
cles to control the simulation. Table 5 
lists the special instructions that specify 
the test sequence. The instructions are 
simple and modeled after the required 
bus operations. Modeling all the assem- 
bly-language operation codes would 
have been too complex and would have 
been less useful. The model needed only 
10 instructions, and these instructions 
include setting the address and data for 
a given operation. With these instruc- 
tions, you can check all the various 
modes of reading and writing the SRAM. 
The testbench uses simple combinations 
of commands to implement all the re- 
quired test scenar- 
ios. The model has 
two implementa- 
tions. The simpler 
model has the test 
sequence embed- 
ded within the 
model itself, imple- 
mented as VHDL 
code that you have 
to compile each 
time you change 
the test. This procedure violates your de- 
sire to decouple high-level tasks from 
low-level tasks. In the second procedure, 
a test language-parsing engine drives the 
simulation. The text-parsing engine may 
seem to add an extra level of complexi- 
ty, but it offers advantages in flexibility 
and ease of use. Because an external text 
file includes the test sequence, the pro- 
gram need not compile the sequence be- 
fore it runs. This feature lets you quick- 
ly and easily add test scenarios. In effect, 
this method offers an application-inde- 
pendent simulation language that you 
can use in any system that requires this 
functionality on an i960 CPU. 

Several options for implementing the 
SRAM models exist. You can implement 
the models as an array, simply storing 
data in array locations according to the 
location addresses. Another choice is to 
build a model that can transfer address 
and memory data to a disk file for later 
verification. This example does not re- 
quire the memory to pass large amounts 
of data through the design. The engineer 
designed the memory with two 16-word- 
deep arrays to store data— one at the 



lower address space of the model and the 
other at the top end. The designer im- 
plemented the second array to allow 
RAM access to roll over from one page to 
another. The design uses the SRAM ad- 
dress to index into the arrays. The mod- 
el responds to standard write-enable, 
output-enable, chip-select, address, and 
data-RAM-control signals. The design 
stores data in the array upon execution 
of a legal write cycle and retrieves data af- 
ter execution of a legal read cycle. In ad- 
dition to storing and retrieving data, the 
model can also check SRAM timing re- 
quirements. You can select the timing pa- 
rameters to be none, minimum, typical, 
or maximum. The minimum access time 
doesn't matter, so the designer set it to 
zero delay. 
The chip-select decoding model is a 
simple combinator- 
ial-decoder function 
with no parameter 
checking. The mod- 
el duplicates the 
function- and prop- 
agation-delay tim- 
ing of the circuit. 
You can select the 
delay as none, mini- 
mum, typical, or 
maximum. The 
latched-transceiver model is a simple se- 
quential model with limited parameter 
checking for data setup and hold. 

The simple function of this circuit re- 
quires simple test cases. You accomplish 
each of the bus-cycle types for the i960 
model by writing to the SRAM and read- 
ing the data back. The test cases include 
single write then read, bank or 1 start, 
burst write then read, bank or 1 start, 
with or without CPU wait states, with or 
without SRAM page break, and overlap 
CPU wait states with page break. These 
relatively simple cases are sufficient to 
test the functions of the memory-control 
CPLDs. The CPU model checks the data- 
path by verifying that the data written is 
the same when read back. The SRAM 
models, which require proper control 
signals to store and retrieve data, check 
the control signals. The models have tim- 
ing checks distributed throughout them- 
selves. The CPU, SRAM, and latched- 
transceiver models all incorporate code 
to verify proper signal timing. If a test 
does not meet required setup, hold, or 
pulse timings, the model that detected 
the error reports each error. You can 
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model. 

You can easily check the listing from 
the behavioral-model testbench. The last 
line tells whether any errors exist. If there 
are no errors, your job is done. If a failure 
occurs, a quick inspection reveals the lo- 
cation, along with a clue about the loca- 
tion and the cause of the failure. The test- 
bench automatically runs all checks each 
time you run the simulation.D 
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